The MS Classmark (CM) information elements (IEs) 1 and 2 contain MS/UE (user equipment) specific information that is descriptive of MS capabilities and the protocol reference version, such as the revision level of the MS protocol software. The IE is included in some Radio Resource management messages as well as in Mobility Management messages, such as the LOCATION UPDATING REQUEST message. This particular IE has been defined since the Global System for Mobile Communications (GSM) Phase 1 in standard GSM TS 04.08, and more recently in the Third Generation Partnership Project (3GPP) standard TS 24.008 for Release 1999 (R99) and later releases.
Since the protocol versions in GSM phase 1, GSM phase 2 and R99 differ substantially from one another, there is a requirement that all MSs should indicate their support of GSM phase 1, GSM phase 2 or R99 (and later) version of the protocol when attempting to register with the wireless network.
When a network detects a MS that is operating with an earlier protocol version level than the current version level of the network, the network is thereby informed that it is not to use signalling elements and procedures that would not be backwards compatible with the MS that is operating in accordance with the earlier revision level. In practice, the network is typically able to perform a fallback to the previous version of the protocol, thereby assuring compatibility with the MS.
When a network detects the presence of a MS having a later protocol version level than that of the current network protocol, then the network is obviously unable to switch to an operational capability that was defined later than the network's reference version of the protocol. However, this is normally not a problem since the (later) protocol is or should be designed to cope with such situations. If this were not done, then (by example) the introduction of GSM phase 2 and R99 MSs would need to be delayed until every network in the world had been updated to the same protocol revision level in order to insure interoperability.
A similar problem was previously identified when moving from GSM phase 1 to phase 2, and is documented in GSM 09.90, v4.9.0, in clause 5.3.6.1 (annex 4).
As was discussed in a publication Tdoc GP-021695, presented by Nokia Corporation at 3GPP TSG-GERAN meeting #10, Helsinki, 24–28 Jun. 2002, it has been found that some networks fail to provide service to R99 MSs that, according to the R99 requirements, indicate their revision level in the Mobile Station Classmark 1 and 2 IEs. As the problem appears to be in the serving network, it thus affects both home (HPLMN) users and roaming users, if they have a R99 or later MS. The problem is also not limited to any specific radio access network or core network, as any single mode or multi-mode R99, or later, MS is rejected in the same way. In fact, a large number of the existing commercial networks currently reject a Classmark IE that contains a R99 revision level, meaning that a R99 MS cannot obtain service in about half of the currently existing GSM networks.
It may be the case that one reason for this failure mode is a non-uniform interpretation of the meaning of the statement “reserved for future use” by writers of network protocol software, as some implementors of network software may interpret this to mean the same as the defined term “reserved”, which if encountered by the network is intended to trigger error handling procedures.
In addition to the rejection of the R99 MS Classmark, as discussed above, other compatibility problems have been observed. For example, the following errors concerning interoperability with R99 MSs have been observed in R97/R98 GSM networks.
Mismatch of R99/R97 Send Sequence Numbers
This error has been described in detail in Tdoc G2-020790, presented by Ericsson in 3GPP TSG GERAN WG2 meeting #11-bis, Atlanta Ga., 7–11 Oct. 2002. The consequence of this common error is that R99 terminals do not obtain any service from the network since the location update procedure fails. This error only occurs if the upgrade from R97 to R99 in the network is performed in an inconsistent manner.
Certain R97 Serving General Packet Radio System (GPRS) Support Node (SGSN) Implementations do not Accept the R99 Quality of Service (QoS) Information element
During field testing it has been discovered that there are R97/R98 SGSNs in commercial use that do not accept the R99 QoS information element. The R99 QoS information element has been defined in 3GPP TS 24.008 V3.12.0, clause 10.5.6.5 to be a fixed length, type 4 IE with a length of 13 bytes. The rejection of the R99 QoS IE by a R97 SGSN is an implementation error, since the R97 QoS information element defined in 3GPP TS 04.08 V6.18.0, clause 01.5.6.5, is a fixed length, type 4 IE with a length of five bytes. A correct SGSN implementation should decode only the known length of this IE, i.e., five bytes, and skip the remaining eight bytes added in the R99 version of the specification. For a R97 receiver, an IE longer than expected is not to be considered an error (see 04.07, ch 11.2). In R99, the QoS parameters defined for R99 should always be used in the air interface (see 23.107 ch. 9.1.2.1).
Incorrect Padding of Control Messages Leading to GPRS Failure
During field testing it has been discovered that there exist R97/R98 Base Station Systems (BSS) in commercial use that incorrectly terminate a Temporary Block Flow (TBF) resource assignment message. This results in a situation in which a correctly implemented R99 MS sees R99 extension parameters assigning an Enhanced GPRS (EGPRS) TBF to the MS. Therefore, a R99 MS either accepts the message (if the MS supports EGPRS) or rejects the message (if the MS does not support EGPRS). In both cases, however, the TBF fails (either the establishment of or the operation on the TBF) and leads to a situation in which GPRS cannot be used at all by the MS.